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ABSTRACT 

As  part  of  the  Advanced  Launch  System  technology  development  effort  begun  in  1989,  the  Air  Force  initiated  a 
program  to  automate  to  the  extent  possible  the  processing  of  NDE  data  from  the  inspection  of  sohd  rocket  "^^tors  during 
fabrication  The  computerized  system,  called  the  Automated  NDE  Data  Evaluation  System  or  AND^,  was  deve  oped  under 
contract  to  Martin  M^ietta.  The  generic  ANDES  system  has  been  tailored  to  support  inspection  tasks  at  two  Air  Logistic 
SJers  in  the  Air  Force.  These  centers  are  the  Ogden  Air  Logistic  Center  at  Hill  AFB,  UT  and  the  San  Antonio  Air  Logistic 

Center  at  Kelly  AFB,  TX. 

The  ANDES  system  can  be  configured  to  process  digital  or  digitized  NDE  data  from  any  source^  The  system  will 
analyze  the  data  for  anomalies,  classify  detected  anomalies,  and  make  a  recommendation  on  the  serviceability  of  the 
component  containing  the  anomalies  based  on  established  criteria.  The  ANDES  system  Hill  AFB 
X-ray -computed  tomography  (CT)  images  in  support  of  the  surveillance  activities  on  the  Minuteman  III  third  sta^e  solid 
rocket  motors.  The  system  functions  as  a  supplement  to  the  visual  image  analysis  effort  and  as  an  automated  report 
generation  and  electronic  report  storage  device. 

The  ANDES  system  installed  at  Kelly  AFB  also  processes  CT  images.  The  components  which  are  supported  are  the 
oil  scavenge  assembly  from  the  F-lOO  aircraft  engine,  the  yoke  pivot  block  casting  for  T-38  aircraft,  and  a  torpedo  housing 
casting  Kelly  AFB  inspects  for  the  NAVY.  The  ANDES  system  screens  the  casting  data  images  for  void  content  and  cracks 
and  a  braised  joint  on  the  oil  scavenge  tube  for  leak  paths  and  total  wetted  area. 

The  paper  will  briefly  discuss  the  ANDES  development  history,  the  system  hardware  and  software  architectures 
employed  at  both  Hill  AFB  and  Kelly  AFB,  and  a  brief  description  of  the  performance  of  the  operational  systems. 

Keywords:  automated  NDE  processing,  NDE,  aging,  solid  rocket  motors,  computed  tomography 

1.  INTRODUCTION 

The  Air  Force  has  invested  significantly  in  inspection  technology  in  the  past  20  years.  The  investment  supporting 
the  rocket  propulsion  mission  has  been  mainly  in  the  implementation  or  development  of  data  acquisition  technology. 

Although,  some  data  processing  technology  was  also  implemented  with  all  of  the  data  acquisition  development,  the 
assessment  of  the  components  being  inspected  is  still  based  on  visual  interpretation  of  the  NDE  data  A  joint  R&D  effort 
between  NASA  and  the  Air  Force  was  undertaken  in  1989  to  develop  a  new  generation  of  launch  vehicles.  This  effort  was 
called  the  Advanced  Launch  System,  ALS,  later  renamed  the  National  Launch  System,  NLS.  The  goal  was  to  reduce  the  cost 
of  placing  a  payload  in  low  earth  orbit  by  an  order  of  magnitude,  to  $300  per  pound.  The  Air  Force  managed  a  technology 
pro<^ram  for^S  named  NDE  for  Solid  Rocket  Boosters  (NDE  for  SRB’s).  The  goal  of  the  program  was  to  totally  automate 
the  NDE  data  processing  and  decision  processing  for  the  in-process  and  end  item  acceptance  during  the  manufacture  of  the 
solid  rocket  boosters  for  the  ALS  effort.  This  project  was  not  completed  as  originally  planned  due  to  cancellation  of  the  ALS 
effort,  but  the  contract  did  deliver  two  operational  systems  with  reduced  capabilities. 

2.  PROJECT  HISTORY 

The  NDE  for  Solid  Rocket  Boosters  program  was  conceived  as  a  $12M  effort  consisting  of  four  phases  spanning 
five  years  The  program  was  to  conclude  with  the  delivery  of  a  production  ready  system  to  support  the  fabrication  of  the  solid 
rocket  booster  design  being  developed  in  other  ALS  projects.  The  tasks  in  the  first  phase  of  the  program  were  to  develop  the 
operational  requirements,  develop  the  functional  design  of  the  automated  system,  to  generate  hardware  and  software 
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architectures  to  be  incrementally  developed  in  the  subsequent  three  phases,  and  to  define  the  test  and  validation  plan  to 
demonstrate  that  the  system  performed  properly.  The  automated  system  was  called  the  Automated  NDE  Data  Evaluation 
System,  or  ANDES.  Although  it  was  to  be  developed  for  ALS,  from  the  program’s  beginning,  the  plan  was  to  build  ANDES 
as  generic  and  as  flexible  as  possible. 

In  the  second  year,  the  ALS  funding  was  cut  dramatically.  In  the  third  year,  most  of  the  ALS  programs  were  ended. 
The  NDE  for  SRB’s  effort  was  early  in  phase  two,  finalizing  the  system  design  and  beginning  to  write  software.  The  program 
was  reorganized  to  deliver  a  functioning  prototype  system  on  the  remaining  contract  funds.  While  preparing  to  end  the  effort, 
the  Air  Force  searched  for  other  benefactors  to  continue  the  development.  Two  were  found,  Kelly  AFB  and  Hill  AFB.  A 
new  task  in  the  NDE  for  SRB’s  contract  was  added  in  the  third  quarter  of  FY  91  for  the  Science  and  Engineering  Laboratory 
at  Kelly  AFB.  This  task  was  to  deliver  an  operational  version  of  ANDES  to  process  X-ray  CT  images  for  several 
miscellaneous  components  the  Lab  was  fabricating  or  refurbishing.  In  the  third  quarter  of  FY  92  another  task  was  added  to 
develop  an  ANDES  system  which  would  process  X-ray  CT  images  on  Minuteman  third  stage  solid  rocket  motors  at  Hill  AFB. 
These  added  tasks  permitted  the  program  to  extend  the  development  of  ANDES  into  operational  systems.  These  two  systems 
do  not  have  all  of  the  functional  capabilities  intended  in  the  original  ALS  design,  but  they  do  contain  the  fundamental 
operational  capabilities,  plus  the  software  and  hardware  architecture  of  the  original  system  design. 

3.  ANDES  DESIGN  FOR  ALS 

The  original  ANDES  design  for  ALS  supported  all  the  various  functions  for  the  fabrication  of  a  solid  rocket  motor. 
Figure  1  shows  a  top  level  functional  diagram  of  the  ANDES  system  as  it  was  designed.  The  two  ovals  represent  the  two 


laii©iiilall  IS©'!?il©vsj  Hoatnal 


Process /  Product 
Relationships  ^ 


■ 

1 

Failure  Modes  & 
Anaiysis  Routines^ 


Figure  1.  Functional  Diagram  of  ANDES  Software. 


major  software  modules,  the  seven  cylinders  represent  various  classes  of  information  to  be  stored  in  the  system  data  base,  and 
the  computer  terminals  represent  three  of  the  user  interfaces  with  the  system.  The  arrows  depict  the  directions  of  information 
flow.  The  Inspection  System  (IS)  module  is  the  interface  to  a  NDE  data  acquisition  system.  This  figure  shows  only  one  of 
these  modules,  however,  ANDES  was  designed  to  service  multiple  acquisition  systems  simultaneously.  The  actual  system 
would  have  a  tailored  IS  module  for  each  acquisition  system  that  is  connected.  What  is  not  apparent  from  this  figure  is  how 
the  software  system  is  configured  and  managed  from  a  global  standpoint.  The  main  user  interface  for  setup,  maintenance,  and 
overall  system  management  is  implemented  as  part  of  the  Process  /  Product  Analysis  (PPA)  module.  The  hardware 
architecture  used  for  the  ANDES  system  was  chosen  primarily  due  to  the  operational  requirements  dictated  by  the  fabrication 
process  layout,  several  locations  widely  separated  in  distance.  This  required  a  system  with  several  workstations  connected  on 


a  local  area  network.  The  data  storage  and  data  processing  would  be  distributed  among  the  various  workstations. 

Fi<’ure  1  makes  referenee  to  the  term  “defect  token”  which  needs  to  be  defined  here.  In  figure  1,  the  arrow  from  the 
Inspection  System  oval  to  the  Process  /  Product  Analysis  oval  is  labeled  with  two  types  of  data,  defect  tokens  and  raw  data^ 
Defect  tokens  are  small  packets  of  text  information  which  describe  the  characteristics  of  a  detected  feature,  see  figure  2.  The 
approach  of  “tokeniring”  the  information  about  a  detected  feature  was  adopted  in  order  to  minimize  the  amount  of  data  being 
permanently  stored  and  shared  between  processes. 


Token: 

{ 

class:  propellant 
radiaLcenter:  151.019318 
angular_center:  153.066589 
major_extent_iTim:  9.614274 
major_extent_deg:  3.167152 
iTiinor_extent„mm:  6.342917 
radiaLextent:  4.267532 
orientation:  85.215927 
area:  36.944504 
rel_amplitude:  0.874997 
min_dist_to_bore:  0.154984 
max_dist„to__bore:  4,4225 1 6 
min_dist_to_ins:  128.180756 
max__dist_to_ins:  133.870804 


Typed  Anomaly: 

2:  gouge  -  accept.  PSC  Script  used:  3RDG.gouge.any  (New) 
angle  center:  153.07  deg.;  major  extent:  9.61mm; 

radial  center:  15 1 .02  mm;  radial  extent:  4.27  mm; 

minor  extent:  6.34  mm;  major  extent:  3.17  deg.; 

area:  36.94  sq.  mm;  relative  amplitude:  0,87  %; 

min.  distance  to  bore:  0.15  mm;  max.  distance  to  bore:  4.42  mm, 
min.  distance  to  ins.:  128.18  mm;  max,  distance  to  ins..  133.87 


mm; 

axial  start: 


57.15  mm;  axial  extent: 


6,35  mm; 


Figure  2.  Example  Token  (left)  and  Corresponding  Typed  Anomaly  (right). 


Functional  diagrams  of  the  IS  and  PPA  modules  are  shown  in  figures  3  and  4  respectively.  Figure  3  shows  a  detailed 
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Figure  3.  Functional  Diagram  of  Inspection  System  Module. 


functional  diagram  of  the  interior  processes  of  the  IS  module  as  it  was  originally  designed.  The  top  three  boxes  in  the  figure 
represent  the  software  features  which  would  handle  the  internal  functions  for  communicating  with  the  rest  of  the  ANDES 
system.  The  Control  and  Dispatch  Module  in  the  IS  is  the  inspection  system  operator’s  interface  for  managing  and  scheduling 
the  IS  processes  and  for  responding  to  system  messages  and  requests.  The  Acquisition  Module  is  the  interface  with  the  dam 
acquisition  system  for  the  IS.  The  Processing  Module  is  responsible  for  performing  the  image  analysis  and  feature  extraction 
from  the  NDE  data.  The  Raw  Data  Storage  is  the  location  of  the  NDE  data  files  generated  by  the  acquisition  system. 

Looking  at  an  operational  scenario  is  the  best  way  to  clarify  the  functioning  of  the  IS  module.  The  production 
mana^rer  issues  a  message  to  the  ANDES  system  requesting  the  normal  thru-transmission  ultrasonic  inspection  on  motor  serial 
number  A-005  which  is  being  transported  to  the  ultrasonic  facility.  The  ANDES  system  relays  the  message  to  the  appropriate 
Inspection  System  module  which  places  the  request  in  the  request  queue,  informing  the  operator  of  an  inspection  request. 
When  the  motor  arrives,  the  operator  mounts  it  in  the  inspection  system  and  initiates  thru-transmission  data  acquisition. 

When  data  acquisition  is  completed  the  data  is  stored  in  Raw  Data  Storage.  The  operator  then  issues  a  command  to  the  IS  to 
initiate  data  processing  using  the  normal  thru-transmission  processing  template.  This  template  controls  the  actions  of  the 
Processing  Module  for  retrieval  of  the  raw  data,  feature  extraction,  token  generation,  and  transmission  of  any  token 
information  generated  to  the  ANDES  data  base.  The  IS  module  also  issues  two  messages  of  its  own.  One  goes  to  the 
originator  of  the  data  request  informing  him  that  the  action  is  complete  and  the  other  goes  to  the  decision  system  module  of 
ANDES  informing  it  that  there  is  a  set  of  anomaly  tokens  to  be  processed. 

It  was  envisioned  that  a  fully  functional  ANDES  system  would  be  integrated  closely  enough  with  the  data  acquisition 
systems,  through  the  respective  IS,  that  adaptive  scan  features  would  be  available.  This  would  mean  that  if  the  decision 
system  modules  of  ANDES  detected  problems  with  the  data  or  if  there  were  difficulty  processing  anomalies  from  the  token 
information,  a  request  for  a  non-standard  inspection  could  be  issued  automatically  to  the  IS.  This  inspection  request  would 
contain  the  specifics  of  the  inspection  procedure  to  gather  the  additional  data  needed  in  order  to  properly  assess  the  part.  This 
request  would  be  examined  by  the  inspection  system  operator  and  he  could  either  perform  the  requested  operation  or  consult 
with  the  production  manager  to  deny  the  request  and  instruct  ANDES  to  use  the  existing  data. 

The  largest  module  of  the  ANDES  system  is  the  Process  /  Product  Analysis  module.  This  module  controls  the  main 
user  interface  for  the  system.  The  system  management  functions  and  much  of  the  system  setup  and  tailoring  are  also 
performed  through  this  module.  In  addition,  the  PPA  module  performs  the  analysis  and  decision  rendering  functions  on  the 
tokens  passed  from  the  IS  module.  The  functional  diagram  of  the  analysis  and  decision  processes  is  shown  in  figure  4. 


Figure  4.  Analysis  and  Decision  System  Functional  Diagram. 


The  PPA  module  periodically  polls  the  message  area  of  the  ANDES  data  base  for  a  message  that  a  list  of  tokens  has 
been  generated  by  an  IS  module.  When  this  message  is  detected,  PPA  retrieves  the  list  of  tokens  and  proceeds  to  process 
them  using  a  template  which  has  been  designated  by  the  operator.  As  shown  in  figure  4,  the  image  and  token  data  are 
received  from  the  IS  module.  The  image  data  would  then  be  checked  to  verify  the  quality  of  the  data.  If  the  quality  was 
sufficiently  low,  the  PPA  could  issue  a  message  to  the  IS  requesting  the  data  be  replaced  or  permission  to  proceed  with 
substandard  quality.  The  token  data  describing  each  anomaly  or  feature  in  the  NDE  data  would  proceed  to  the  Typer.  In  this 
step  the  token  data  is  classified  by  type,  size,  orientation  and  location,  see  the  example  in  figure  2.  Once  typed,  the  tokens  are 
passed  to  the  specification  comparator  which  checks  each  anomaly  against  the  appropriate  product  specification  criteria.  In 
this  step  each  anomaly  is  categorized  as  being  within  or  outside  of  tolerances.  No  further  processing  would  be  done  on  those 
anomalies  that  are  within  tolerances.  They  would  simply  be  stored  and  reported.  Anomalies  exceeding  the  tolerances  would 
be  ta<’<^ed  as  rejectable  defects  and  would  then  be  subjected  to  engineering  analysis  procedures  built  into  the  PPA  module  to 
estim“ate  the  remaining  margin  of  safety  and  the  projected  impact  on  performance  of  the  part.  All  of  this  information  would 
then  be  passed  to  the  final  decision  module  to  issue  the  recommended  disposition  of  the  part,  accept  or  reject.  If  required,  the 
system  would  then  assemble  a  material  review  board  (MRB)  report  to  support  the  MRB  process  that  would  decide  if  the  part 
could  still  be  used  with  the  lower  margin  of  safety,  if  the  part  could  be  repaired,  or  if  the  part  must  be  scrapped. 

The  data  processing  step  which  compares  the  typed  anomaly  information  to  product  specifications  is  perforrned  at 
three  different  levels.  The  first  level  is  the  single  anomaly  check.  At  this  level  each  reported  anomaly  is  checked  against 
specifications  for  a  single  anomaly  of  the  appropriate  type.  For  example,  if  a  void  less  than  one  half  inch  in  diameter  is 
acceptable,  then  any  single  void  smaller  than  this  is  marked  acceptable  and  the  system  proceeds  to  the  next  anomaly.  Once  all 
individual  anomalies  have  been  checked,  the  system  then  uses  a  nearest  neighbor  criteria  to  consider  combined  anomaly 
effects.  In  this  check,  the  system  is  instructed  that  anomalies  of  similar  type  which  fall  within  some  threshold  distance  of  one 
another  are  to  be  considered  as  a  combined,  larger  anomaly.  This  combined  anomaly  condition  is  then  checked  against  the 
established  criteria.  If  the  inspection  data  is  two  dimensional  in  form,  such  as  an  ultrasonics  C-scan,  the  anomaly  processing 
is  now  complete.  If  the  data  is  three  dimensional  in  nature,  such  as  contiguous  CT  images,  a  third  level  of  processing  is  used. 
For  the  case  of  CT  images,  the  first  two  processing  levels  are  performed  on  each  CT  image  or  slice.  Once  all  slices  have  been 
processed  individually,  the  system  checks  each  anomaly  in  a  slice  for  an  adjoining  anomaly  in  the  next  contiguous  slice.  In 
this  manner  anomalies  which  span  several  slices  are  identified  and  treated  as  a  single  anomaly.  The  slice  spanning  anomaly  is 
then  compared  to  the  appropriate  criteria  to  test  for  acceptability. 

It  is  very  important  that  the  decisions  the  ANDES  system  would  make  could  be  traced  and  verified.  Two  methods 
were  designed  to  provide  this  verification  process.  The  first  method  was  the  institution  of  an  audit  trail  of  the  anomaly 
processing.  The  user  can  display  the  acceptance  criteria  for  any  of  the  reported  anomalies  and  the  system  will  insert  the 
coiTesponding  values  from  the  anomaly.  In  this  way  the  user  can  determine  which  criteria  controlled  the  accept  /  reject 
decision  for  the  anomaly  and  what  the  actual  value  was  of  the  anomaly  characteristic  which  generated  the  decision.  The 
second  method,  which  was  designed  but  not  fully  developed,  is  a  data  simulation  module.  This  module  would  allow  the 
operator  to  develop  a  realistic  set  of  data  containing  anomalies  using  segments  of  actual  data.  In  this  way,  the  simulated  data 
contained  the  characteristics  of  real  data.  The  synthesized  data  sets  with  the  user  prescribed  anomalies  would  then  be  fed  to 
the  ANDES  system  and  processed.  The  results  could  then  be  compared  to  the  known  characteristics  of  the  data  to  determine 
how  the  ANDES  system  was  functioning. 

4.  SYSTEM  FLEXIBILITY 

It  has  been  stated  that  the  ANDES  system  was  designed  to  be  as  generic  and  flexible  as  possible.  The  purpose  was 
to  create  a  system  which  could  be  applied  to  as  broad  a  scope  of  products  and  processes  as  possible  and  to  minimize  the  cost 
of  tailoring  the  system  to  a  specific  application.  The  system  was  also  designed  to  maintain  several  different  processing 
configurations  and  allow  the  operator  to  select  the  configuration  to  be  used  from  a  menu.  This  capability  would  allow  a  single 
ANDES  installation  to  service  multiple  production  programs  which  use  the  same  facilities  for  fabrication  and  inspection. 

The  core  processes  of  the  ANDES  system  are  totally  generic.  These  processes  include  the  data  base  management 
system,  the  communication  and  messaging  system,  and  the  data  analysis  and  decision  processing  engine.  It  is  the  peripheral 
processes  and  data  handling  which  are  unique  to  each  application.  The  parts  of  the  system  which  are  unique  include  the 
interface  to  the  individual  data  acquisition  systems,  the  image  analysis  process  which  extracts  the  features  from  the  NDE  data, 
the  specific  anomalies  and  defects  which  are  applicable  to  the  inspected  object,  the  specifications  for  the  appropriate 
anomalies,  and  the  contents  of  displayed  or  printed  reports.  ANDES  employs  two  approaches  to  make  the  tailoring  of  these 


unique  processes  much  simpler  by  greatly  reducing  the  amount  of  “hard  code”  which  has  to  be  written  and  compiled. 

The  first  of  these  approaches  is  the  use  of  an  image  processing  system  which  executes  user  definable  networks  of 
standard  and  custom  data  processing  modules.  The  overall  ANDES  configuration  file  contains  the  name  of  the  image 
processing  procedure  to  be  used  and  the  PPA  passes  this  name  to  the  IS  when  the  request  for  data  is  issued.  When  the  NDE 
data  from  the  acquisition  system  is  available,  the  IS  issues  the  command  to  the  image  processing  system  to  execute  the 
procedure  name  received  from  the  PPA.  The  image  processing  procedure  contains  the  details  about  which  image  processing 
modules  to  use,  in  what  order,  what  the  input  parameters  are  for  the  modules,  and  any  other  unique  data  that  are  required. 
This  arrangement  eliminates  the  need  to  make  hard  code  changes  in  the  main  execution  stream  of  the  IS  module  to  implement 
changes  in  the  image  processing.  Any  image  processing  code  which  must  be  written  and  compiled  is  limited  to  writing 
custom  modules  for  networks  executed  by  the  image  processing  system.  The  networks  themselves  are  generated  using  an 
interactive  interface  in  the  image  processing  system.  Using  this  interface,  assemblages  of  standard  and  custom  modules  can 
be  hooked  together  to  perform  the  necessary  functions  without  modifying  the  IS  or  other  ANDES  system  software.  An 
example  of  a  network  of  processing  modules  is  shown  in  figure  5. 


The  second  approach  is  the  use  of  a  script  language  interpreter  to  control  and  execute  most  of  the  processes  in  the 
analysis  and  decision  system  loop.  The  scripting  language  is  patterned  after  the  method  described  in  the  ADA  Language 
Reference  Manual,  ANSI/MIL-STD-1815A-1983.  This  approach  is  very  much  like  an  interpreted  BASIC  language  for  desk 
top  computers.  Using  the  ANDES  script  editor  window,  the  user  writes  text  files  which  define  the  processing  to  be  done. 
Parameter  values  describing  the  detected  anomalies  are  retrieved  from  the  anomaly  tokens  and  processed  by  the  script.  The 
script  then  exports  the  results  in  the  form  of  parameter  values  which  are  stored  in  the  data  base  for  use  by  subsequent 


processes.  The  script  can  also  initiate  the  execution  of  external  programs,  if  needed,  and  retrieve  results  from  the  program 
when  it  is  finished. 

An  example  of  a  script  is  shown  in  figure  6.  This  script  would  be  executed  by  the  typer  function  to  determine  the 
type  of  a  detected  anomaly.  The  characteristics  used  by  the  typer  script  are  stored  in  the  token  information  for  the  anomaly. 
In  the  script  shown  in  figure  6  there  are  ten  input  parameters  which  are  retrieved  from  the  token.  These  parameters  are 
defined  between  the  statements  “external_variables:”  and  “end_external_variables;”.  These  parameters  consist  of  one  text 
string  and  nine  numbers.  The  purpose  of  the  script  is  to  establish  the  type  of  the  anomaly  so  the  only  output  value  is  a  text 
strino  called  “type”.  The  main  part  of  the  script  is  a  series  of  if-then-else  logic  statements  which  lead  to  various  value  for  the 
anomaly  type  depending  on  the  values  of  the  input  parameters.  Similar  scripts  are  used  by  the  specification  comparator  and 
the  operational  criticality  analyzer. 


external  variables: 
in_text:  class; 

in_number:  rel_amplitude,  major_extent_mm,  major_extent_deg, 
minor_extent_mm,  axial_start,  min_dist_to_bore,  min_dist_to_ins, 
orientation; 

out_text:  type; 
end_extemal_variables; 

if  (rel_amplitude  >=  1 .0)  then 
type  :="inclusion"; 

elsejf  (class  =  "propellant")  then 
if  ((major_extent_mm  >  3)  and 

((major_extent_mm  /  minor_extent_mm)  >=  2.0))  then 
if  (rel_amplitude  >=  0.65)  then 
type  :=  "liner  wipe"; 

elsejf  (((orientation  >  80)  or  (orientation  <  -80))  and  //  parallel 
(min_dist  Jojns  <=  5))  then 
type  :=  "tear"; 
else 

type  :=  "crack"; 
endjf 
else 

if  (min_distjo_bore  <  1)  then 
type  :=  "gouge";  //  or  surface  void,  treated  the  same, 
else 

type  :=  "void"; 

Figure  6.  Excerpt  from  ANDES  Typer  Script. 


5.  OPERATIONAL  SYSTEMS 

The  preceding  paragraphs  have  described  how  the  ANDES  architecture  was  designed  and  how  the  system  would 
have  operated  if  the  original  four  phases  of  the  NDE  for  SRB’s  contract  had  been  completed.  Instead,  the  major  software 


development  phases,  phases  three  and  four,  of  the  original  program  were  deleted  due  to  loss  of  ALS  funds  and  phases  five  and 
six  were  added  to  deliver  operational  systems  to  Kelly  .\FB  and  Hill  AFB  respectively,  "^e  system  requirements  for  ph^es 
five  and  six  were  significantly  less  than  for  the  ALS  project.  While  the  original  ANDES  hardware  and  software  architectures 
were  followed,  a  number  of  the  features  were  not  implemented  in  the  operational  systems.  However,  if  there  is  a  need,  some 
or  all  of  these  features  could  be  added  at  a  later  date.  The  tailoring  of  ANDES  for  each  base  consisted  of  s^e  features  whic 
were  common  to  both  and  other  features  which  are  unique.  The  common  features  will  be  described  first.  The  unique  features 
of  each  site  will  be  discussed  in  separate  sections. 

Each  ANDES  installation  at  the  two  Air  Force  bases  consist  of  two  SUN  workstations.  In  each  installation,  all  of  the 
ANDES  hardware  is  located  at  the  data  acquisition  site  and  services  only  one  data  acquisition  system.  The  data  acquisition 
system  at  each  installation  is  X-ray  CT.  Due  to  the  proximity  of  the  ANDES  systems  to  the  data  acquisition  systeins  and  the 
limited  number  of  workstations,  much  of  the  message  traffic  was  not  implemented.  In  both  cases,  the  operator  of  the 
acquisition  system  and  the  operator  of  ANDES  is  the  same  person,  and  notifications  requesting  inspection  data  from  the  PPA 
module  to  the  IS  module  are  not  needed.  Both  sites  are  implemented  using  an  object  oriented  data  base  and  an  image 
processing  engine  which  employs  user  defined  networks  of  standard  and  custom  processing  modules  to  perform  the  data 
analysis.  Three  of  the  processing  blocks  for  the  Process/Product  Analysis  module  shown  in  figure  4  were  not  implemented  m 
either  system.  These  processing  blocks  are  the  data  quality  analyzer,  operational  criticality  analyzer,  and  the  report  generator 

for  MRB  actions. 


5.1  Kelly  AFB  system 

Under  the  new  phase  five  of  the  contract,  a  version  of  ANDES  was  developed  and  installed  at  Kelly  AFB  to  assess 
several  relatively  small  parts  which  were  being  inspected  by  the  Kelly  Science  and  Engineering  Laboratory  using  X-ray  CT. 
Schematic  diagrams  of  these  parts  are  shown  in  figure  7.  The  operational  environment  at  Kelly  AFB  is  that  of  a  laboratoiy 
rather  than  a  production  facility.  Their  needs  required  that  the  image  processing  function  of  the  ANDES  system  be  much 
more  flexible  than  a  typical  installation,  so  the  IS  “module”  was  in  fact  implemented  as  a  stand-alone  interactive  process. 


Figure  7.  NN- ANDES  Processed  Components  for  Kelly  AFB. 


While  it  did  interact  with  the  ANDES  system,  it  did  so  in  a  much  more  autonomous  manner  than  would  normally  be  the  case. 
This  IS  was  implemented  using  the  KHOROS  software  system  which  is  a  public  domain  data  visualization  and  processing 
environment.  In  addition,  they  were  interested  in  evaluating  the  effectiveness  of  neural  networks  for  performing  the  feature 
recognition  tasks.  Therefore,  an  additional  stand-alone  IS  “module”  was  developed  M  the  Aspirin  /  Migraine  neural 
network  system.  As  a  result  of  the  neural  net  IS,  this  version  of  the  software  was  named  NN- ANDES. 

A  top  level  functional  diagram  of  the  NN-ANDES  system  at  Kelly  AFB  is  shown  in  figure  8^  In  the  box  on  the  far 
left  side  of  the  figure,  SA-ALC  stands  for  San  Antonio  Air  Logistics  Center.  The  CT  system  used  at  Kelly  AFB  is  a  420 
thousand  electron  volt  system  manufactured  by  Scientific  Measurement  Systems,  SMS  The  labeled  arrows  in  the 
indicate  the  data  or  message  flow  between  functions.  The  comments  near  the  function  boxes  or  oval  indicate  the  tasks  which 

are  performed  by  the  various  functions. 


•  Data/Image  Processing 

•  Quantification 
•Token  Generation 


•  Persistent  Data 

•  Notifications 


Figure  8.  Functional  Diagram  of  NN-ANDES  System. 


The  requirement  for  a  very  flexible- IS  significantly  increased  the  complexity  of  operating  the  system.  The  increased 
flexibility  forced  much  more  interaction  by  the  operator  than  would  normally  be  the  case.  The  CT  data  acquisition  and  image 
reconstruction  are  controlled  from  the  microVAX  computer  of  the  SMS  CT  system.  The  CT  images  are  then  stored  on  the 
microVAX’s  data  disks.  A  stand-alone  image  file  conversion  program  is  then  run  to  reformat  the  image  data  files  in 
preparation  for  transfer  to  the  SUN  workstation.  The  operator  then  initiates  the  transfer  of  the  image  files  via  ethernet  from 
the  microVAX  to  the  SUN.  The  next  step  is  to  process  the  images  through  the  neural  net  IS  or  the  KHOROS  based  IS  to 
extract  the  information  on  possible  anomalies  and  to  generate  the  anomaly  tokens.  These  tokens  are  automatically  stored  m 
the  NN-ANDES  data  base.  When  the  tokens  are  available,  the  operator  initiates  the  PPA  process  which  evaluates  the  tokens 
to  identify  actual  defects  and  to  compare  the  defects  to  the  acceptance  criteria.  A  report  can  then  be  generated  and  displayed 
for  review  or  printed. 

The  data  set  for  the  scavenge  tube  consists  of  ten  CT  slices  and  represents  100  percent  coverage  of  the  braised  area. 
The  typical  scan  and  image  reconstruction  time  to  acquire  the  data  set  is  one  hour.  An  additional  one  to  one  and  a  half  hours 
is  required  to  convert  the  image  files  and  process  them  through  the  NN-ANDES  system.  The  yoke  casting  required  a  custom 
scan  plan  for  each  part  so  there  isn’t  a  typical  number  of  images  in  a  data  set.  An  average  processing  time  for  this  part  to 
acquire  the  necessary  images,  convert  them  into  the  SUN  format  and  processes  them  through  NN-ANDES  is  one  and  one  half 
to  two  hours  The  data  set  for  the  torpedo  housing  casting  consisted  of  only  three  images.  However,  due  to  the  size  of  the 
part,  the  data  acquisition  time  is  substantially  greater.  The  total  acquisition,  conversion,  image  processing  time  for  this 


casting  is  about  three  hours.  • 

The  use  of  neural  networks  for  processing  the  data  at  Kelly  AFB  did  not  prove  very  effective.  The  specific 
applications  seemed  not  to  lend  themselves  to  this  approach.  Another  big  contributing  factor  was  the  lack  of  sufficient  data 
sets  which  contained  a  sufficient  number  and  mix  of  anomalies  to  properly  train  the  neural  networks.  Although,  it  was  and 
interesting  approach,  it  was  abandoned  in  favor  of  the  more  traditional  capabilities  of  the  KHOROS  software. 

5.2  Hill  AFB  system 

The  system  installed  at  Hill  AFB  was  tailored  to  support  the  inspection  of  Minuteman  stage  three  rocket  motors  and 
has  been  named  MM-ANDES.  This  system  was  greatly  simplified  in  operation  compared  to  the  system  at  Kelly  AFB.  This 
was  possible  due  to  the  well  defined  nature  of  the  operation  for  Minuteman.  A  top  level  functional  diagram  of  MM-ANDES 
is  shown  in  figure  9.  In  the  box  on  the  far  left  side  of  the  figure,  00-ALC  stands  for  Ogden  Air  Logistics  Center.  The  term 
ICT-1500  refers  to  the  ARACOR ICT-1500,  nine  million  electron  volt  CT  system.  The  labeled  arrows  in  the  figure  indicate 
the  data  or  message  flow  between  functions.  The  comments  near  the  function  boxes  or  oval  indicate  the  tasks  which  are 
performed  by  the  various  functions. 


Figure  9.  Functional  Diagram  of  MM-ANDES  System. 


Figure  10  shows  the  hardware  configuration  and  location  of  software  for  the  MM-ANDES  system.  The  box  entitled 
SCATHA  is  the  master  workstation.  This  workstation  houses  the  user  interface,  DBMS,  and  Process/Product  Analysis 
functions  shown  in  figure  9.  MAGELLAN  is  the  slave  workstation  in  MM-ANDES.  All  of  the  IS  functionality  is  located 
here.  The  remaining  box  in  figure  10  depicts  the  ARACOR  CT  system.  The  controller  for  the  CT  operation  is  a  VAX  1 1/750 
computer.  This  computer  controls  all  of  the  data  acquisition  and  image  reconstruction  operations.  It  should  be  noted  that 
there  is  not  a  direct  connection  between  the  CT  system  and  MM-ANDES.  The  data  transfer  from  the  acquisition  system  to 
MM-ANDES  is  performed  via  nine  track  tape.  This  was  necessary  because  the  VAX  computer  in  the  acquisition  system 
cannot  communicate  over  an  ethernet.  In  order  for  the  VAX  system  to  perform  data  acquisition  and  image  reconstruction 
simultaneously,  all  processes  not  essential  to  those  functions  had  to  be  eliminated  from  the  VAX’s  operating  system.  This 
included  the  ethernet  communication  interface.  Instead,  the  image  data  set  is  written  to  two  tapes  which  are  carried  to  the 
MM-ANDES  system  and  read. 

The  operator  uses  SCATHA  to  initiate  all  MM-ANDES  operations,  including  those  performed  on  MAGELLAN. 

The  operation  can  be  described  as  a  three  “button”  process.  Read  Tape,  Process  Data,  and  Review  Report.  The  first  step  in 
the  processing  chain  on  MM-ANDES  is  to  import  the  image  data  files  from  the  CT  system.  The  operator  inserts  the  first  of 


ANDES 


Figure  10.  MM- ANDES  Hardware  and  Software  Configuration. 

two  tapes  containing  the  image  and  label  files  into  the  MM-ANDES  tape  drive  and  selects  the  READ  TAPE  process  from  the 
menu  in  the  main  user  interface.  The  user  interface  then  issues  a  message  to  the  inspection  system  module  to  read  the  tape  in 
the  tape  drive.  The  IS  reads  the  label  file  for  the  first  image  on  the  tape  and  extracts  the  information  describing  the  motor. 

This  information  includes  the  motor  type,  motor  serial  number,  and  acquisition  date.  The  data  base  is  checked  for  an  existing 
entry  for  the  motor  type  and  serial  number.  If  there  is  no  existing  entry  for  this  motor,  one  is  generated.  The  data  base  is  then 
checked  for  an  existing  entry  for  the  acquisition  date.  If  one  exists,  in  other  words,  the  data  set  is  being  reprocessed  the  old 
results  will  be  overwritten.  More  likely,  a  new  entry  is  created  for  the  acquisition  date  of  the  data  set  being  imported.  The 
also  generates  a  subdirectory  named  as  the  acquisition  date  in  the  processed  data  directory.  After  the  image  files  have  been 
processed  they  are  moved  from  the  raw  data  directory  to  the  processed  data  directory.  Having  initialized  the  system  d^ata 
base  and  created  the  necessary  file  directories  ,  the  IS  proceeds  to  read  in  all  images  on  the  tape,  convert  the  image  and  labe 
file  for  each  CT  slice  into  a  single  file,  and  store  the  converted  files  in  the  raw  data  directory.  When  the  end  of  the  tape  is 
reached,  a  message  is  displayed  on  the  main  interface  terminal  informing  the  operator  that  the  reading  of  the  tape  has  been 
completed.  If  there  are  any  more  tapes  to  be  read,  the  operator  loads  the  next  tape  and  starts  the  reading  process  again. 

The  next  step  in  the  processing  chain  is  the  analysis  of  each  CT  image  to  extract  features  which  may  be  anomalies. 
The  operator  opens  the  process  data  window  from  the  user  interface,  and  from  a  list  of  available  data  sets,  selects  the  data  set 
to  be  processed.  The  user  interface  scans  the  raw  data  storage  for  all  image  files  with  the  selected  serial  number  and 
acquisition  date  and  generates  a  “process  image”  message  on  each  one  for  the  IS.  This  message  contains  the  motor  serial 
number,  acquisition  date,  and  the  slice  number.  The  message  also  includes  the  image  processing  procedure  to  be  used.  The 
IS  retrieves  a  process  image  message  from  the  message  queue,  searches  the  raw  data  directory  for  the  image  file,  and  initiates 
the  execution  of  the  image  processing  procedure  identified  in  the  message.  When  the  image  processing  is  finished,  the  IS 
writes  all  tokens  which  were  generated  to  the  front  of  the  image  data  file,  moves  the  image  file  to  the  processed  data  directory, 
and  informs  the  PPA  that  a  token  list  is  available  for  this  CT  slice.  The  IS  then  retrieves  the  next  process  image  message  and 
repeats  the  cycle  until  all  the  messages  are  gone. 

The  image  processing  tasks  in  the  MM-ANDES  IS  were  implemented  using  the  commercial  AVS  software  produced 
by  Advanced  Visual  Systems,  Inc.  This  software  operates  similar  to  KHOROS  in  that  it  is  a  processing  framework  that 
executes  networks  of  standard  and  custom  processing  modules  which  perform  the  various  tasks  for  image  analysis.  The 
“process  ima«e”  message  which  the  PPA  sends  to  the  IS  includes  the  name  of  the  specific  network  to  use  for  the  processing  of 
the  slice  number  indicated  in  the  message.  For  the  MM-ANDES  installation,  all  slices  were  processed  by  the  same  network. 
However  this  network  references  a  user  developed  text  file  of  configuration  information  which  describes  the  unique 
processing  requirements  for  various  zones  in  the  motor  geometry.  The  network  then  chooses  appropriate  branches  in  the 
processing  stream  to  execute  based  on  this  configuration  file.  In  this  manner,  each  individual  CT  image  is  processed  by  the 
most  appropriate  image  analysis  methodology. 


The  PPA  module  retrieves  the  “token  list  available”  message  from  the  message  queue,  retrieves  the  image  file  name, 
and  proceeds  to  process  the  tokens  found  by  the  IS.  There  are  two  passes  made  on  the  tokens  in  order  to  complete  the 
procLsing.  The  first  pass  is  to  process  all  tokens  for  a  single  CT  slice.  Each  token  is  examined  to  determine  if  it  is  an 
Lomaly  or  a  known  motor  feature  based  on  a  priori  knowledge  of  the  motor  geometry.  True  anomalies  are  then  typed  and 
compared  to  the  single  flaw  acceptance  criteria  for  the  anomaly  type.  Once  all  anomalies  in  the  slice  have  been  processed,  all 
anomalies  of  the  same  type  are  checked  against  the  nearest  neighbor  specifications.  Specifications  are  given  to  t  e 
defining  the  threshold  distance  for  an  anomaly  type  which  states  that  two  flaws  of  the  same  type  nearer  each  other  than  the 
threshold  distance  will  be  treated  as  a  single,  larger  anomaly.  Once  all  nearest  neighbors  have  been  identified  and  tokens  are 
generated  describing  the  combined  anomaly,  these  new  tokens  are  compared  against  the  appropriate  criteria  for  acceptance. 


Once  all  slices  have  been  processed  by  the  PPA  in  the  first  pass,  the  operator  initiates  the  final  processing  pass.  In 
this  step,  all  anomalies  in  a  slice  are  examined  to  determine  if  there  is  an  anomaly  of  Ae  same  type  at  the  same  location 
(within  some  user  defined  threshold  tolerance)  in  a  contiguous  slice.  At  the  end  of  this  processing  pass,  any  anomaly  which 
spans  two  or  more  CT  slices  will  have  been  identified  and  compared  against  the  appropriate  criteria  for  acceptance.  It  is 
necessary  for  the  operator  to  initiate  this  processing  step  because  the  system  has  no  way  of  knowing  if  all  the  data  set  images 
were  in  the  raw  data  directory  prior  to  starting  the  single  slice  processing  pass.  It  is  possible  that  additional  images  were 
acquired  and  loaded  into  the  MM-ANDES  system  after  the  single  slice  processing  was  started.  Therefore,  the  system  must  be 
told  when  to  perform  the  tests  for  slice  spanning  anomalies. 


The  final  step  in  the  processing  chain  is  the  generation  of  a  report  of  the  analysis  results.  The  operator  may  request 
the  system  venerate  and  display  a  report  of  the  results  at  any  time  during  the  token  processing  or  after  all  processing  has  been 
completed  The  operator  selects  the  review  report  process  from  the  user  interface  and  selects  from  the  list  of  available  serial 
numbers  and  acquisition  dates  the  specific  report  desired.  This  report  is  displayed  to  the  screen  for  review  by  the  operator. 
Non-erasable  comments  may  be  added  to  the  report  by  the  operator  as  needed.  When  desired,  a  paper  copy  of  the  report  can 

be  printed. 

The  third  stage  data  set  consists  of  120  image  files  and  an  equal  number  of  label  files.  Two  tapes  are  required  to 
transport  the  data  set  to  MM-ANDES.  A  total  of  forty  minutes  is  required  for  the  IS  to  input  the  data  set  from  tapes.  The 
imaoe  processing  takes  six  to  seven  hours.  The  time  varies  based  upon  the  number  of  reconstruction  artifacts  and  general 
quality  of  the  images  and  upon  the  total  number  of  anomalies  detected.  Once  all  CT  slices  in  a  data  set  have  been  processed, 
the  check  for  slice  spanning  anomalies  is  performed.  This  process  takes  another  one  or  two  minutes. 


6.  SUMMARY 

The  system  at  Hill  AFB  has  been  in  service  for  more  than  a  year;  the  one  at  Kelly  AFB  more  than  two  years.  The 
reports  from  Kelly  AFB  have  all  been  positive.  No  problems  with  the  functioning  or  decision  making  of  the  system  were 
reported.  Due  to  the  closure  of  the  San  Antonio  Air  Logistics  Center,  the  workload  for  the  NN-ANDES  system  did  not 
materialize  as  expected  and  the  system  is  now  inactive.  The  reports  on  the  MM-ANDES  system  at  Hill  AFB  have  also  been 
positive.  A  significant  number  of  data  sets  have  now  been  processed  by  the  MM-ANDES  system.  One  software  bug  was 
discovered  in  a  non  critical  function  of  the  system  and  has  been  eliminated.  This  bug  involved  the  automatic  data  base 
preparation  by  the  read  tape  function  when  it  attempted  to  process  a  second  set  of  data  (new  acquisition  date)  for  an  existing 
motor  serial  number.  The  problem  was  easily  circumvented  by  preparing  the  new  entry  in  the  data  base  manually,  but  the 
error  in  the  software  has  since  been  corrected.  The  bug  did  not  affect  the  image  analysis,  defect  detection,  or  decision  making 
processes  of  the  system.  A  few  other  operation  related  “glitches”  have  been  encountered,  but  these  have  involved 
inconsistences  in  the  data  files  generated  on  the  data  acquisition  system  and  not  software  problems  with  MM-ANDES. 

The  Air  Force  and  NASA  initiated  the  NDE  for  Solid  Rocket  Boosters  program  in  1989  to  develop  an  automated 
system  for  processing  NDE  data.  Although  the  original  focus  of  the  effort  was  changed  due  to  changes  in  National  priorities, 
much  of  the  intent  of  the  effort  was  never-the-less  achieved  with  the  delivery  of  the  two  operational  systems  to  Kdly  AFB  and 
Hill  AFB.  The  successful  use  of  automated  decision  making  on  digital  NDE  data  has  been  demonstrated.  The  original 
hardware  and  software  architectures  have  proved  to  be  very  successful  demonstrating  the  intended  design  flexibility  for 
tailoring  to  dissimilar  applications  without  major  overhauls  to  the  core  software. 


